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(57) ABSTRACT 

A system for packet parsing and data reconstruction in an 
IEEE 1394-1995 serial bus network includes a network 
interface unit, a processing unit, and a memory wherein an 
operating system resides. The operating system includes a 
streaming services module and a multimedia Application 
Program Interface (API) module. The network interface unit 
receives a stream of packets from a transmission device. 
Each packet includes a header portion, and may also include 
a data portion. The data portion, if present, stores data 
content generated from source data organized in accordance 
with a predetermined format. The streaming services mod- 
ule stores and then parses the received packets. A method for 
packet parsing and data reconstruction includes the steps of 
receiving a packet stream; storing a first and a second 
packet; locating a header portion within the first packet; and 
determining whether a header portion within the second 
packet immediately follows the header portion within the 
first packet. The method may also include the steps of 
determining whether the first packet corresponds to a par- 
ticular boundary within the source data, such as the begin- 
ning of a digital video (DV) frame; and transferring data 
content within the first packet to a buffer. 

17 Claims, 8 Drawing Sheets 
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SYSTEM AND METHOD FOR PACKET FIG. 2 is a block diagram showing a CIP packet 20. The 

PARSING AND DATA RECONSTRUCTION IN CIP packet 20 includes a CIP header field 22 and a CIP data 

AN IEEE 1394-1995 SERIAL BUS NETWORK field 28. The CIP header field 22 spans a first and a second 

CIP header quadlet 24, 26 (i.e., 8 bytes total), while the CIP 
5 data field 28 spans 480 bytes. The CIP header field 22 stores 

FIELD OF THE INVENTION source node identification and timing information, plus 

The presenl invention relates to the field of communicat- parameters that define manners in which the information 

ing packetized data between network node devices. More contained in the CIP data field 28 may be interpreted, 

particularly, the present invention relates to the field of A device that receives a stream of IEEE 1394-1995 

processing packetized data by parsing isochronously 10 isochronous packets 10 typically stores the contents of each 

received data packets to facilitate data reconstruction opera- such packet's payload data field 16 in a receive buffer. Thus, 

tions. when payload data fields 16 contain CIP packets 20, a first 

receive buffer contains a sequence of CIP packets 20. Once 

BACKGROUND OF THE INVENTION me first receive buffer fc m> the receiving device stores 

International standard IEEE 1394-1995 , "IEEE 1394- 15 subsequent CIP packets 20 in a second receive buffer. 

1995 Standard For A High Performance Serial Bus," defines Hardware and/or software concurrently processes the CIP 

an economical, scalable, high-speed serial bus architecture. packet sequence in the first receive buffer to reconstruct data 

This standard provides a universal input/output connection contained therein in accordance with a format expected by 

for interconnecting digital devices including, for example, an application program. For example, software may process 

audio-visual equipment and personal computers. 20 CIP packet sequences by extracting video data and gener- 

The IEEE 1394-1995 standard defines a peer-to-peer atin B a complete video frame in accordance with a standard 

network architecture characterized by point-to-point signal- forinat such as Di S ital video CDV). A DV frame comprises 

ing. A network implemented in accordance with the IEEE 120 kilobytes of compressed digital audio and video data, 

139-1995 standard comprises a plurality of nodes, where organized as a set of Data in Frame (DIF) sequences. Once 

each node includes one or more ports. Ports may be linked 25 constructed, the DV frame may be delivered to an applica- 

together via standardized cabling, subject to a restriction that ^on program for decompression and playback, 

disallows closed loops. In terms of physical topology, the Due to timing and data availability considerations, the 

IEEE 1394-1995 standard provides for a non-cyclic network CIP data field 28 within a particular CIP packet 20 may not 

having multiple ports and finite branches. contain any information. That is, some CIP packets 20 may 

The IEEE 1394-1995 standard supports both asynchro- 3 ° contain CIP header information only, being empty in terms 

nous and isochronous information transfers. Asynchronous of data content. Processing sequential CIP packets 20 under 

transfers are operations that communicate data from a source | nc assumption that data immediately follows CIP header 

node to a destination node and take place as soon as information may therefore produce data reconstruction 

permitted after initiation. Asynchronous transfer operations 35 errors. 

do not provide a mechanism for maintaining temporal The generation of a complete DV frame occasionally 

relationships within an information stream between succes- requires data from more than one receive buffer. Moreover, 

sive data transfers. An example of an application appropriate the first receive buffer occasionally contains data forming an 

for asynchronous data transfer is communication of a still incomplete DV frame, followed by some or all data neces- 

image or text document. Control commands can also be sent ^ sary to generate a first complete DV frame. Some applica- 

asynchronously. tion programs are incapable of accepting an incomplete DV 

Isochronous transfers provide information delivery char- frame. Hence, processing CIP packets 20 under the assump- 

acterized by predictable, bounded latency; guaranteed band- ^oii that 1) a full DV frame can be generated using a single 

width; and on-time data reception. Time intervals between receive buffer; or 2) a first received CIP packet 20 may be 

particular events have essentially the same duration at both 45 used t0 h& & n constructing a first complete DV frame may 

the transmitting and receiving applications. Isochronous also produce data reconstruction errors, 

transfer is particularly advantageous in real-time multimedia ADVncTOC iktwcmt™ kt 

applications, such as the real-time transfer of digital audio SUMMARY OF THE INVENTION 

and video data between a digital video camera and a digital The present invention comprises a system and method for 

television. 50 parsing the content of packets received from a source node 

The IEEE 1394-1 995 standard defines a structured packet within a networked node environment. The networked node 

into which information is encapsulated for isochronous environment preferably comprises an IEEE 1394-1995 

transfer upon the bus. FIG. 1 is a block diagram showing an serial bus network that includes the source node and at least 

IEEE 1394-1995 isochronous packet 10. The IEEE 1394- one destination node. The source node serves as a data 

1995 isochronous packet 10 includes a header field 12; a 55 transmission unit that transfers a stream of IEEE 1394-1995 

header cyclic redundancy check (CRQ field 14; a payload isochronous packets 10 to the data reception unit. Each IEEE 

data field 16; and a payload data CRC field 18. 1394-1995 packet 10 contains a CIP packet 20. The data 

The IEEE 1394-1995 standard does not specify particular reception unit parses the CIP packets 20, and reconstructs 

formats for the contents of the payload data field 16. Rather, data obtained therefrom in accordance with a predetermined 

the organization of payload data in accordance with a so format. The source node serves may be, for example, a 

particular format and the interpretation of payload data field digital camcorder, a digital videocassette recorder, or a 

contents are functions of the transmitting and receiving computer system. The destination node is preferably a 

applications, respectively. In order to facilitate interoperabil- computer system. The destination node could be essentially 

ity between a wide range of digital devices, payload data any device or system capable of processing a received 

fields 16 should encapsulate data in accordance with a es information stream in accordance with the present invention, 

standardized format. One such format that has gained wide Within the computer system, an IEEE 1394-1995 intcr- 

acceptance is the Common Isochronous Protocol (CIP). face unit receives the stream of IEEE 1394-1 995 packets 10, 
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and transfers the CIP packets 20 contained therein to a first 
isochronous receive buffer. Upon filling the first isochronous 
receive buffer, the interface unit begins filling a second 
isochronous receive buffer, and so on. After the first isoch- 
ronous receive buffer is full, a parsing state machine locates 5 
a CIP header field 22 within a first CIP packet 20 in the first 
isochronous receive buffer. The parsing state machine deter- 
mines whether the first CIP header field 22 is immediately 
followed by a CIP header field 22 within a second CIP 
packet 20. If so, the first CIP packet 20 is empty. The parsing 
stale machine then determines whether the second CIP 
packet 20 is empty, and so on. 

Upon finding a CIP header field 22 that is immediately 
followed by a CIP data field 28, the parsing state machine 
transfers DV data within the CIP data field 28 to a user 15 
buffer. The parsing state machine transfers CIP data field 
contents to the user buffer only after finding a non-empty 
CIP packet 20 that corresponds to the beginning of a DV 
frame. After transferring DV data to the user buffer, the 
parsing state machine considers subsequent CIP packets 20 ^ 
within the first isochronous buffer. After considering each 
packet within the first isochronous buffer, the parsing state 
machine considers CIP packets 20 within the second isoch- 
ronous buffer, and so on. In the event that the interface unit 
has stored a given non-empty CIP packet 20 as a first partial ^ 
CIP packet and a second partial CIP packet across two 
successive isochronous receive buffers, the parsing state 
machine transfers DV data from within each partial CIP 
packet to the user buffer. 

Once a user buffer is full, it preferably contains ah entire ^ 
DV frame. The parsing state machine returns the filled user 
buffer to the stream class driver. The stream class driver 
delivers complete DV frames to a multimedia Application 
Program Interface (API) module, which may then perform 
operations such as frame decompression and rendering. 35 

One aspect of the present invention is a method for 
parsing a stream of packets received from a transmission 
device, where a subset of packets within the stream include 
data content. The data content is generated from, or forms a 
portion of, source data that is organized in accordance with 40 
a predetermined formal. The predetermined format may be, 
for example, a standard DV frame format. The method 
includes the step of receiving a stream of packets, where 
such packets preferably comprise IEEE 1394-1995 isochro- 
nous packets, each of which includes a CIP packet 20. Each 45 
CIP packet 20 includes a header field 22, and may include 
a data field 24. The method further includes the steps of 
storing a first and a second received packet, and locating a 
header portion within the first packet. In the preferred 
embodiment, the header portion may be located by succes- 50 
sively comparing stored quadlets with the expected formal 
of CIP header information. The method additionally 
includes the step of determining whether a header portion 
within a second stored packet immediately follows the 
header portion within the first stored packet If so, the first 55 
stored packet is empty in terms of data content, in which 
case the data content of the second stored packet can be 
considered. 

The method may also include the step of determining 
whether the first packet corresponds to a particular boundary « 
within the source data, such as the beginning of a DV frame. 
Additionally, the method may include the step of transfer- 
ring data content from the first packet to a destination buffer. 
The packet stream is preferably received isochronously, in 
accordance with the IEEE 1394-1995 standard. 6 s 

The method may further include the steps of storing a first 
portion of the second packet in a first receive buffer, and a 
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second portion of the second packet in a second receive 
buffer. If the second packet includes data content, the 
method may include the steps of transferring data content 
associated with the second packet from the first receive 
buffer to a destination buffer, and transferring data content 
associated with the second packet from the second receive 
buffer to the destination buffer. The method may additionally 
include the step of advancing to a location within the second 
receive buffer that is beyond the portion of the second packet 
stored therein. 

Another aspect of the invention is a system for parsing a 
stream of packets received from a transmission device, 
where a subset of packets within the stream include data 
content. The system includes a stream reception unit coupled 
to receive the stream of packets; a processing unit; and a 
memory wherein a first buffer, a second buffer, a stream 
storage module, and a parsing module reside. The stream 
storage module receives a stream of packets from the stream 
reception unit, and stores a packet sequence in a receive 
buffer. The parsing module determines whether successive 
packets residing in the receive buffer include data content, 
and, if so, stores such data content in a destination buffer. 
Preferably, the stream of packets is communicated 
isochronously, in accordance with the IEEE 1394-1995 
standard. In such a case, the stream reception unit includes 
circuitry for interfacing to an IEEE 1394-1995 serial bus. 

The system may further include an API module within the 
memory that is responsive to a signal generated by the 
parsing module. This signal indicates that the API module 
may begin processing the contents of the destination buffer, 
for example, by performing DV frame decompression and 
rendering operations. 

Still another aspect of the invention is a data communi- 
cation network in which a sending node configured to 
transmit data packets is coupled via a network segment to a 
receiving node configured to receive and parse such packets. 
Each transmitted packet includes header information, while 
a subset of transmitted packets also include data content. 
The receiving node includes a network interface unit 
coupled to receive a stream of packets; a processing unit; 
and a memory in which a receive buffer, a destination buffer, 
a packet storage module, and a parsing module reside. The 
packet storage module stores a sequence of received packets 
in the receive buffer. The parsing module determines 
whether packets within the receive buffer include data 
content, and, if so, stores such data content in the destination 
buffer. In the preferred embodiment, the data packets are 
communicated isochronously from the sending node to the 
receiving node, and the network segment is an IEEE 1394- 
1995 serial bus. 

The memory may further include an API module that is 
responsive to a signal received from the parsing module. 
This signal indicates that the API module may initiate 
processing operations upon the contents of the destination 
buffer. Such operations may include, for instance, DV frame 
decompression and rendering operations. 

According to yet another aspect of the present invention, 
an IEEE 1394 serial bus network includes an IEEE 1394 
serial bus that couples a transmitting device and a receiving 
device. The transmitting device is configured to transmit a 
stream of packets upon the IEEE 1394 serial bus, where a 
subset of such packets include data content. The receiving 
device includes a stream reception unit coupled to receive 
the stream of packets; a processing unit; and a memory. The 
memory includes a receive buffer, a destination buffer, a 
stream storage module, and a parsing module. The stream 
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storage module stores a sequence of packets received from tional serial bus cables 104. The system organi2ation shown 

the stream reception unit in the receive buffer. The parsing in FIG. 3 is considered herein for ease of understanding, 

module determines whether successive packets residing The. data transmission unit 102 transmits source data to 

within the receive buffer include data content, and, if so, me computer system 110 in the form of an isochronous 

stores such data content in the destination buffer. 5 multimedia data stream. The data transmission unit 102 may 

According to another aspect of the present invention, a be, for example, a digital video camera, such as a Sony 

computer readable medium stores program instructions for DCR-TRV10 digital camcorder (Sony Corporation, Tokyo, 

directing a processing unit to parse a stream of packets. The Japan). Alternatively, the data transmission unit 102 could 

packets are received from a transmission device, where a be a digital videocassette recorder (VCR), or even another 

subset of such packets include data content generated from 1° computer system 110. 

source data organized in accordance with a predetermined p r i or to transmission, the source data exists or is captured 

format. The program instructions may direct the processing m accordance with a predetermined format. In the preferred 

unit to perform the steps of locating a header portion within embodiment, the source data comprises Digital Video (DV) 

a first packet; determining whether a header portion within data organized as a series of standard DV frames 200. Those 

a second packet immediately follows the header portion 13 skilled in the art will recognize that in an alternate 

within the first packet; determining whether the first packet embodiment, the source data could be organized in accor- 

corresponds to a particular boundary within the source data, dance with another format. 

such as the beginning of a DV frame; and transferring data mQ 4Ais a Wock dia am definin a standard DV frame 

content within the first packet to a buffer. ^ m ^ DV frame 200 ^ m kiloby , eSj md compri ses 

BRIEF DESCRIPTION OF THE DRAWINGS a Kt of DIF «q u «K*s 210. In environments supporting the 

National Television Standards Committee (NTSC) video 

FIG. 1 is a block diagram of an IEEE 1394-1995 isoch- format, the DV frame 200 includes 10 DIF sequences 210. 

ronous packet. In phase Alternating Line (PAL) environments, the DV 

FIG. 2 is a block diagram of a Common Isochronous ^ frame 200 includes 12 DIF sequences 210. Each DIF 

Protocol packet. sequence 210 comprises a header section 212, a subcode 

FIG. 3 illustrates an exemplary system organized in section 214, a Video Auxiliary (VAUX) section 216, and an 

accordance with the present invention for packet parsing and AV data section 218. Taken together, the aforementioned 

data reconstruction. sections 212, 214, 216, 218 occupy 150 DIF blocks 230. 

err" ia '„ „ u I j' „ r . -t a T\\t c ,„ Each DIF block 230 spans 80 bytes, and includes a 3 byte 

FIG. 4A is a block diagram of a standard DV frame. 30,, . . , . a . ,\ ,,, , 

„„ .„ . , , f , block identification (ID) field 232 followed by a 77 byte data 

FIG. 413 is a table snowing a standard byte content g e j d 234 

definition within a DIF block ID field. rr „ ' . . , . , . A , , , 

. HG. 4B is a table showing a standard byte content 

FIG. 5 is a block diagram of a preferred layered software definition within a block ID field 232. In least-significant to 

architecture for a streaming services module of the present 35 mQS t-significant bit order, a first byte 240 includes 4 

invention. sequence bits (Seq 0 through 3), a reserved bit (RSV), and 

FIG. 6 is a block diagram showing a first, a second, and 3 section type bits (SCT 0, 1, and 2). A second byte 242 

a kth isochronous receive buffer, which also shows an includes 3 reserved bits (RSV), a zero, and four DIF 

exemplary sequence of CIP packets within the first and sequence bits (D Seq 0 through 3). Lastly, a third byte 244 

second isochronous receive buffers. ^ includes 8 DIF block number bits (DBN 0 through 7). The 

FIG. 7 is a state diagram showing a preferred sequence of beginning of a D V frame 200 corresponds to a) the first byte 

states and stale transition conditions for a parsing state 240 having its section type bits equal to 0, and its reserved 

machine of the present invention. bit equal to 1; b) the second byte 242 having its DIF 

r ^„ ri , 1 TI „ nrn ™ IIvrfni , _ Tr , sequence bits equal to 0 and its reserved bits equal to 1; and 

D ™^Sn D ^? n^P^^L mE 45 <D «» *ird byte 244 having its DIF block number bits equal 

PREFERRED EMBODIMENT to 0. 

FIG. 3 illustrates an exemplary system 100 organized in Hardware and/or software within the data transmission 

accordance with the present invention for packet parsing and unit 102 converts the source data into the multimedia data 

data reconstruction in an IEEE 1394-1995 serial bus net- stream. The multimedia data stream preferably comprises a 

work. The system 100 comprises an IEEE 1394-1995 com- 50 sequence of IEEE 1394-1995 isochronous packets 10, each 

pliant data transmission unit 102 that is coupled via an IEEE of which contains a CIP packet 20. Referring again to FIG. 

1394-1995 serial bus cable 104 to a data reception unit, 2, each CIP packet 20 includes a CIP header field 22 and a 

which preferably comprises a computer system 110. CIP data field 28. In the preferred embodiment, the CIP data 

The serial bus cable 104 forms a segment of an IEEE field 28 will usually include DV data. However, the CIP data 

1394-1995 network that couples two nodes together, ss field 28 will occasionally be empty as a result of timing 

namely, the data transmission unit 102 and the computer and/or source data availability considerations, 

system 110. Thus, the serial bus cable 104 provides a Within the CIP header field 22, the first and second CIP 

pathway for isochronous communication between the data header quadlets 24, 26 are subdivided in accordance with a 

transmission unit 102 and the computer system 110. Those predetermined format, in which an SID portion contains a 

skilled in the art will recognize that the system 100 could 60 source node ID that identifies the transmitting node. A DBS 

include data reception devices, data transmission/reception portion contains a value representing the size (in quadlets) of 

devices, and/or additional data transmission units 102 that each data block within the CIP packet 20. In the context of 

are coupled to the computer system 110 via additional serial the present invention, the data blocks present within a CIP 

bus cables 104 in a conventional manner, depending upon packet 20 are preferably DIF blocks 230. An FN field 

the number of ports supported by the computer system 110. 65 contains a fraction number that indicates the number of data 

Similarly, the data transmission unit 102 could serve mul- blocks into which the CIP packet 20 is divided. As the CIP 

tiple computer systems 110 and/or other devices via addi- data field 28 is defined to occupy 480 bytes, the CIP packet 
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20 can hold 6 DIF blocks 230. A QPC portion contains a 
value representing a number of dummy quadlets added to 
the CIP packet 20 to equalize the size of the divided data 
blocks. If the FN portion indicates that the source packet is 
undivided, then the QPC portion contains a zero value. 5 

An SPH flag indicates whether the data within CIP packet 
20 includes a source-supplied packet header, and is set to a 
logical one value when such a header is present. An rsv 
portion is reserved for future extension. A DBC portion 
contains a data block continuity counter that facilitates 
detection of data block loss. An FMT portion includes a 
format ID that specifies the packet's format type, and an 
FDF portion contains a format-dependent value. Finally, an 
SYT portion is used to synchronize the transmitting and 
receiving nodes. When transmitting isochronous data over 
an IEEE 1394-1995 serial bus network, the SYT portion 
includes a time stamp value. The receiving node can use this 
time stamp value to ensure that data is presented within 
appropriate temporal boundaries. 

Referring again to FIG. 3, the computer system 110 
comprises a processing unit 112; an input/output (I/O) unit 
114; a data storage unit 116; a video and graphics unit 118; 
an IEEE 1394-1995 interface unit 120; and a memory 130 
wherein an operating system 140 and a multimedia appli- 
cation program 180 reside. The operating system 140 
includes a streaming services module 150 and a multimedia 
Application Program Interface (API) module 170. Each of 
the aforementioned computer system elements is coupled to 
a common bus 199. 

The processing unit 112 comprises a microprocessor 
capable of executing stored program instructions. The I/O 
unit 114 comprises conventional circuitry for controlling I/O 
devices and performing particular signal conversions or 
other operations upon I/O data. The I/O unit 114 may 
include, for example, a keyboard controller, a serial port 
controller, and/or digital signal processing circuitry. In a 
preferred embodiment, the I/O unit 114 is coupled to a 
keyboard 190, a mouse 192, and a set of speakers 194. The 
I/O unit 114 may also be coupled to other devices, such as 
a microphone or a joystick. 

The data storage unit 116 may include both fixed and 
removable media using any one or more of magnetic, 
optical, magneto-optical, or other available storage technol- 
ogy. The video and graphics unit 118 comprises conven- 
tional circuitry for operating upon and outputting data to be 
displayed, where such circuitry includes a graphics 
processor, a frame buffer, and display driving circuitry. The 
video and graphics unit 118 is coupled to a display device 
196. 

The IEEE 1394-1995 interface unit 120 is coupled to the 
serial bus cable 104, and comprises physical interface cir- 
cuitry for sending and receiving communications in accor- 
dance with the IEEE 1394-1995 standard. The interface unit 
120 receives a stream of IEEE 1394-1995 isochronous 
packets 10, and preferably removes or separates the header, 
header CRC, and data CRC information from the contents of 
each such packet's payload data field 16. The interface unit 
120 subsequently communicates with operating system ele- 
ments to facilitate CIP packet parsing and data reconstruc- 
tion operations in accordance with the present invention, as 
described in detail below. In a preferred embodiment, the 
IEEE 1394-1995 interface unit 120 comprises a conven- 
tional plug-in interface card. Those skilled in the art will 
recognize that the IEEE 1394-1995 interface unit 120 could 
be implemented in other manners, such as via circuitry that 
is permanently resident upon a motherboard. 
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The memory 130 includes both Random Access Memory 
(RAM) and Read-Only Memory (ROM), and provides stor- 
age for program instructions and data. Within the memory 
130, the operating system 140 comprises program instruc- 
tion sequences that provide services for accessing, commu- 
nicating with, and/or controlling computer system resources. 
The operating system 140 provides a software platform upon 
which application programs may execute, in a manner 
readily understood by those skilled in the art. As described 
in detail below, the streaming services module 150 com- 
prises program instruction sequences that facilitate 1) CIP 
packet reception from the interface unit 120; 2) packet 
parsing and data reconstruction operations in accordance 
with the present invention; and 3) communication with the 
multimedia API module 170. The multimedia API module 
170 comprises an application framework upon which the 
multimedia application program 180 is built, and which 
includes program instruction sequences that facilitate com- 
munication between the multimedia application program 
180 and the streaming services module 150. The multimedia 
application program 180 comprises program instruction 
sequences that rely upon the multimedia API module 170 to 
initiate, manage, and/or control isochronous stream recep- 
tion and the performance of multimedia operations. Such 
multimedia operations may include, for example, the 
decompression and display of Audio/Video (AV) data 
received from a digital camcorder. 

In an exemplary embodiment, the computer system 110 is 
a personal computer having an Intel Pentium III micropro- 
cessor (Intel Corporation, Santa Clara, Calif.); 128 mega- 
bytes of RAM; a 20 gigabyte hard disk drive; a graphics 
accelerator card coupled to a 32 megabyte frame buffer; and 
an IEEE 1394-1995 interface card. The computer system 
110 is coupled to a keyboard, a mouse, a high-resolution 
video display, and a set of speakers. Microsoft Wmdows98 
TM (Microsoft Corporation, Redmond, Wash.) may serve as 
an exemplary operating system 130. The streaming services 
module 150 may be implemented via a set of software 
drivers, and the multimedia API module 170 may be imple- 
mented using the Microsoft DirectShow TM application 
framework. 

The interface unit 120 serially receives an isochronous 
stream that comprises a sequence of IEEE 1394-1995 iso- 
chronous packets 10. Within any particular IEEE 1394-1995 
isochronous packet 10, a CIP packet 20 that contains DV 
data comprises only a small portion of a DV frame 200. The 
multimedia API module 170, however, expects to receive 
significantly larger amounts of D V data at any given time. In 
the preferred embodiment, the multimedia API module 170 
requires that DV data received from the streaming services 
module 150 comprise at least one DV frame 200. 

When the multimedia API module 170 requires or expects 
DV data, it creates a plurality of user buffers, each of which 
is large enough to hold a DV frame 200. Each user buffer is 
preferably a conventional buffer that resides within the 
memory 130. Following their creation, the multimedia API 
module 170 passes the user buffers to the streaming services 
module 150, which acts as an intermediary between the 
multimedia API module 170 and the interface unit 120. 

FIG. 5 is a block diagram showing a preferred layered 
software architecture for the streaming services module 150 
relative to the multimedia application program 180, the 
multimedia API module 170, and the interface unit 120. The 
streaming services module 150 comprises a stream class 
driver 152; a parsing driver 154; a bus class driver 156; and 
a port driver 158. The stream class driver 152 serves as a 
data transport interface to the multimedia API module 170. 
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The stream class driver 152 manages 1) the generation of 
DV frames 200 from DV data received from the parsing 
driver 154; and 2) the transfer of user buffers containing DV 
frames 200 to the multimedia API module 170. 

The parsing driver 154 initiates and performs CIP packet 
parsing and data reconstruction operations in accordance 
with the present invention. The parsing driver 154 preferably 
includes a communication control module 160 and a parsing 
state machine 162. The communication control module 160 
comprises program instruction sequences that manage data 
communication with the stream class driver 152 and the bus 
class driver 156. The parsing state machine 162 parses CIP 
packets 20 in the manner described below with reference to 
FIG. 7. The bus class driver 156 provides the communica- 
tion control module 160 with an interface to the IEEE 
1394-1995 serial bus by communicating with the port driver 
158. Finally, the port driver 158 communicates directly with 
the interface unit 120, and sequentially fills a set of isoch- 
ronous receive buffers with CIP packets 20, as further 
described below. 

The communication control unit 160 attaches a set of 
isochronous receive buffers to the bus class driver 156. FIG. 
6 is a block diagram of a first, a second, and a kth 
isochronous receive buffer 300, 302, 304, where the first and 
second isochronous receive buffers 300, 302 contain an 
exemplary sequence of CIP packets 20. Each isochronous 
receive buffer 300, 302, 304 comprises a conventional buffer 
structure residing within the memory 130 and occupying an 
integral number of quadlets. In the preferred embodiment, 
each isochronous receive buffer 300, 302, 304 spans at least 
120 kilobytes. Additionally, the isochronous receive buffers 
300, 302, 304 are preferably circularly linked. 

As previously indicated, successive CIP packets 20 may 
include both CIP header information and DV data; or CIP 
header information only (i.e., any given CIP packet 20 may 
be empty in terms of DV data content). In the description 
herein, reference to an "empty" CIP packet 20 is taken to 
mean that the CIP packet 20 includes only a first and a 
second CIP header quadlet 24, 26. Empty CIP packets 20 
contain no DV data, and hence do not include a CIP data 
field 28. 

A first CIP packet 20 received may not correspond to the 
beginning of a first D V frame 200. Hence, an initial group 
of CIP packets 20 within the first isochronous receive buffer 
300 may comprise an incomplete DV frame 200. A subse- 
quent CIP packet 20 within the first isochronous receive 
buffer 300 would then correspond to the beginning of a first 
complete DV frame 200. Thus, an amount of DV data 
sufficient to form a complete DV frame 200 may reside 
across multiple isochronous receive buffers 300, 302, 304. 
Moreover, the contents of a single CIP packet 20 may reside 
across two isochronous receive buffers 300, 302, 304 suc- 
cessively filled by the port driver 158. That is, an isochro- 
nous receive buffer 300, 302, 304 may contain a partial CIP 
packet 21. 

Referring again to FIG. 5, the communication control 
module 160 additionally registers the parsing state machine 
162 as a buffer- fill callback function with the operating 
system 140. The parsing state machine 162 is thereby 
automatically entered or executed once an isochronous 
receive buffer 300, 302 is full. After the communication 
control module 160 attaches the set of isochronous receive 
buffers 300, 302, 304 to the bus class driver 156, the bus 
class driver 156 passes the isochronous receive buffers 300, 
302, 304 to the port driver 158. 

The port driver 158 receives CIP packets 20 from the 
interface unit 120, and stores the CIP packets 20 in the first 
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isochronous receive buffer 300 in the order in which they 
were received. Once the first isochronous receive buffer 300 
is full, the port driver 158 stores any partial CIP packet 
contents that exceeded the boundary of the first isochronous 
5 receive buffer 300, as well as successively-received CIP 
packets 20, in the second isochronous receive buffer 302. 
The port driver 158 fills the second and subsequent isoch- 
ronous receive buffers 302, 304 in a manner analogous to the 
filling of the first isochronous receive buffer 300. 
10 Once the first isochronous receive buffer 300 is full, the 
parsing state machine 162 is executed or entered as a 
callback function. FIG. 7 is a state diagram showing a 
preferred sequence of states A through M, inclusive, and 
corresponding state transition conditions for the parsing 
i5 state machine 162. The parsing state machine 162 begins 
operation in state A by sequentially scanning or examining 
quadlets within the first isochronous receive buffer 300 to 
locate a first CIP header quadlet 24 within an initial CIP 
packet 20. The first CIP header quadlet 24 may be identified 
^ by comparing the contents of a quadlet under consideration 
with CIP header field format requirements. 

Upon locating the first CIP header quadlet 24, the parsing 
state machine 162 transitions to state B. In state B, the 
parsing state machine 162 skips past the next sequential 
quadlet, advancing to an isochronous receive buffer location 
at which either 1) a CIP data field 28 would begin if the 
initial CIP packet 20 contains DV data; or 2) another CIP 
header field 2 would begin in the event that the initial CIP 
packet 20 is empty. 
3 q The parsing state machine 162 subsequently transitions to 
state C, and retrieves and examines a next sequential qua- 
dlet. If the quadlet under consideration matches the format 
of a first CIP header quadlet 24, then the initial CIP packet 
20 was empty, in which case the parsing state machine 162 
35 transitions back to state B. If the parsing state machine 162 
encounters a quadlet that fails to match the format of a first 
CIP header quadlet 24, the CIP packet 20 currently under 
consideration includes a CIP data field 28 containing DV 
data. 

40 If the presently-considered CIP packet 20 contains DV 
data, and a first or a new (i.e., empty) user buffer is to be 
filled, the parsing state machine 162 also determines 
whether the beginning of a DV frame 200 has been found, 
that is, whether the parsing operations have yet synchro- 

45 nized to the start of a first or subsequent DV frame 200. The 
parsing state machine 162 preferably makes this determina- 
tion by bytc-masking the contents of the block ID field 232 
within the initial DIF block 230 residing in the presently- 
considered CIP packet's data field 28. An exemplary byte 

50 mask suitable for this purpose is OxOOFFFOEO, or 
OxEOFOFFOO, depending upon big-endian versus little- 
endian ordering considerations. While in state C, the parsing 
state machine 162 also determines whether the presently- 
considered CIP packet 20 resides entirely within the bound- 

55 ary of the current isochronous receive buffer 300, 302, 304. 
In other words, the parsing state machine 162 determines 
whether it is presently considering a partial CIP packet' 21. 

In the event that the parsing operations have not yet 
synchronized to the beginning of a DV frame 200, and the 

60 presently-considered CIP packet 20 resides entirely within 
the boundary of the current isochronous receive buffer 300, 
302, 304, the parsing state machine 162 transitions to state 
M. In state M, the parsing state machine 162 retrieves a next 
sequential quadlet, and then transitions to state B to continue 

65 operations. 

If the parsing operations have not yet synchronized to the 
beginning of a DV frame 200, and the parsing state machine 
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162 is currently considering a partial CIP packet 21, the 
parsing state machine 162 transitions to state D, in which it 
ignores or skips the partial CIP packet's DV data. The 
parsing state machine 162 then transitions to state £, and 
considers a next isochronous receive buffer 302, 304. Fol- 5 
lowing state E, the parsing state machine 162 transitions to 
state F, in which it skips the partial CIP packet 21 present at 
the beginning of the newly-considered isochronous receive 
buffer 302, 304. The parsing state machine 162 then tran- 
sitions to state M. 10 

When the parsing operations have synchronized to the 
beginning of a DV frame 200, and the presently-considered 
CIP packet 20 falls entirely within the bounds of the current 
isochronous receive buffer 300, 302, 304, the parsing state 
machine 162 transitions to state G. In state G, the parsing 15 
state machine 162 copies the DV data contained in the 
current CIP packet's data field 28 to a user buffer. If the user 
buffer does not yet contain a complete D V frame, the parsing 
state machine 162 transitions to state M 

In the event that the user buffer becomes full following tbe 20 
data copy operation in state G, the parsing state machine 162 
transitions to state H, and delivers the user buffer to the 
stream class driver 152. The parsing state machine 162 then 
transitions to state 1 to select a next available or empty user 
buffer for consideration, after which the parsing state 25 
machine 162 transitions to state M. 

Referring again to state C, if parsing operations have 
synchronized to the beginning of a DV frame 200, and tbe 
presently-considered packet is a partial CIP packet 21, the 3Q 
parsing state machine 162 transitions to state J. In state J, the 
parsing state machine 162 copies the DV data from the 
partial CIP packet 21 into a current user buffer. The parsing 
state machine 162 then transitions to state K, and considers 
a next isochronous receive buffer 302, 304. Following state 35 
K, the parsing state machine 162 transitions to state L and 
copies the DV data within the partial CIP packet 21 residing 
at the beginning of tbe newly-considered isochronous 
receive buffer 302, 304 into the current user buffer. Tbe 
parsing state machine 162 next transitions to state M. ^ 

Once a user buffer is full, it preferably contains a complete 
DV frame 200, in which case the parsing state machine 162 
signals an event to the stream class driver 152 to initiate the 
return or delivery of the user buffer to the stream class driver 
152. The parsing state machine 162 subsequently begins 45 
filling a new or empty user buffer with DV data in a manner 
described above. After receiving a full user buffer, the 
stream class driver 152 transfers the DV frame 200 con- 
tained therein to the multimedia API module 170, which 
may then perform frame-based operations such as decoding 50 
and rendering. 

The present invention has been described in terms of 
specific embodiments incorporating details to facilitate the 
understanding of the principles of construction and opera- 
tion of the invention. It will be apparent to those skilled in 55 
the art that modifications may be made in the embodiments 
chosen for illustration without departing from the spirit and 
scope of the invention. For example, the teachings of the 
present invention may be applied to situations in which CIP 
packets 20 selectively contain information organized in 60 
accordance with a format other than DV, such as MPEG -2 or 
MIDI. As another example, the destination node within tbe 
IEEE 1394-1995 network need not be a computer, but could 
be a device such as a digital television or set-top unit that 
includes a processing unit, a memory, an interface unit 120 65 
capable of receiving an isochronous stream, and a parsing 
state machine analogous to that described above. As yet 



another example, one or more elements described herein in 
terms of software could be implemented partially or entirely 
in hardware. In light of the foregoing, reference herein to 
specific embodiments and details thereof is not intended to 
limit the scope of the claims appended hereto. 
We claim: 

1. A method of parsing a packet stream received from a 
transmission device, a subset of packets including data 
content, the data content generated from source data orga- 
nized in accordance with a predetermined format, the 
method comprising: 

receiving the packet stream; 

storing a first and a second packet; 

locating a header portion within the first packet; and 

determining whether a header portion within the second 
packet immediately follows the header portion within 
the first packet; 

wherein the header portion within the first packet com- 
prises a first and a second segment, and 

wherein locating the header portion within the first packet 
comprises: 

retrieving binary information spanning a predetermined 
number of bytes from a first receive buffer; and 

comparing a portion of the binary information with an 
expected format associated with the first segment. 

2. The method of claim 1, further comprising determining 
whether the first packet corresponds to a particular boundary 
within the source data. 

3. the method of claim 2, wherein the boundary is the 
beginning of a DV frame. 

4. The method of claim 1, further comprising transferring 
data within the first packet to a destination buffer. 

5. The method of claim 4, wherein the packet stream is 
received isochronously. 

6. The method of claim 5, wherein the packet stream is 
received in accordance with an IEEE 1394 standard. 

7. The method of claim 1, further comprising advancing 
to a location in the first receive buffer past the second 
segment. 

8. The method of claim 1, further comprising: 
storing a first portion of the second packet in a first receive 

buffer and a second portion of the second packet in a 
second receive buffer. 

9. The method of claim 8, further comprising: 
transferring data content within the second packet from 

the first receive buffer to a destination buffer; and 
transferring data content within the second packet from 
the second- receive buffer to the destination buffer. 

10. The method of claim 8, further comprising advancing 
to a location in the second receive buffer that is beyond the 
second packet. 

11. A system for parsing a stream of packets received from 
a transmission device, a subset of packets including data 
content, the system comprising: 

a stream reception unit coupled to receive the stream of 
packets; 

a processing unit coupled to the stream reception unit; and 
a memory coupled to the stream reception unit and 
comprising: 

a first buffer and a second buffer; 

a stream storage module, for storing a sequence of 

packets received from the stream reception unit in 

the first buffer; and 
a parsing module, for parsing packets stored within the 

first buffer, 
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wherein the parsing module determines whether succes- 
sive packets residing within the first buffer include the 
data content, and wherein the parsing module selec- 
tively stores the data content in the second buffer; 

wherein the memory further comprises an application 5 
program interface module responsive to a signal gen- 
erated by the parsing module, the signal indicating that 
the application program interface module may initiate 
operations upon the contents of the second buffer. 

12. The system of claim 11, wherein the stream of packets 10 
is communicated isochronously. 

13 . The system of claim 11, wherein the stream reception 
unit comprises IEEE 1394 serial bus interface circuitry. 

14. A data communication network comprising: 

a network segment; 15 
a sending node coupled to the network segment, the 
sending node configured for transmitting data packets 
upon the network, a subset of data packets including 
data content; and ^ 
a receiving node coupled to the network segment, the 
receiving node configured for receiving and parsing 
data packets, the receiving node comprising: 
a network interface unit coupled to receive a stream of 

packets; 25 
a processing unit coupled to the network interface unit; 
and 

a memory coupled to the network interface unit and 
wherein a first buffer, 

a second buffer, a packet storage module, and a parsing 30 
module reside, 

wherein the parsing module determines whether packets 
that the packet storage module has stored in the first 
buffer include the data content, and wherein the parsing 
module selectively stores the data content in the second 35 
buffer and further wherein the memory further includes 
an application program interface module responsive to 
a signal generated by the parsing module, the signal 
indicating that the application program interface mod- 
ule may initiate operations upon the contents of the 40 
second buffer. 



181 Bl 

14 

15. The data communication network of claim 14, 
wherein the data packets are communicated isochronously. 

16. The data communication network of claim 14, 
wherein the network segment comprises an IEEE 1394 serial 
bus. 

17. An IEEE 1394 serial bus network including a plurality 
of devices coupled together to communicate isochronous 
data packets, the serial bus network comprising: 

an IEEE 1394 serial bus; 

a transmitting device coupled to transmit a stream of 

packets upon the IEEE 1394 serial bus, a subset of 

packets including data content; and 
a receiving device coupled to receive the stream of 

packets from the IEEE 1394 serial bus, the receiving 

device comprising: 

a stream reception unit coupled to receive the stream of 
packets; 

a processing unit coupled to the stream reception unit; 
and 

a memory coupled to the stream reception unit and 

comprising: 
a first buffer and a second buffer; 
a stream storage module, for storing a sequence of 

packets received from the stream reception unit in 

the first buffer; and 
a parsing module, for examining and parsing packets 

stored within the first buffer, 
wherein the parsing module determines whether succes- 
sive packets residing within the first buffer include the 
data content, and wherein the parsing module selec- 
tively stores the data content in the second buffer; 
wherein the memory further comprises an application 
program interface module responsive to a signal gen- 
erated by the parsing module, the signal indicating that 
the application program interface module may initiate 
operations upon the contents of the second buffer. 
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